Micron Document




Fragile binary interface problem
part 4/8 · 11.2 KB total
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
In complex object-oriented programs or libraries the highest-level classes may be inheriting from tens of classes. Each of those base classes could be inherited by hundreds of other classes as well. These base classes are fragile because a small change to one of them could cause problems for any class that inherits from it, either directly or from another class that does. This can cause the library to collapse like a house of cards as many classes are damaged by one change to a base class. The problem may not be noticed when the modifications are being written if the inheritance tree is complex. Indeed, the developer modifying the base class is generally unaware of which classes, developed by others, are using it.

Solutions

Languages

One solution to the fragile binary interface problem is to write a language that knows the problem exists, and does not let it happen in the first place. Most custom-written OO languages, as opposed to those evolved from earlier languages, construct all of their offset tables at load time. Changes to the layout of the library will be "noticed" at that point. Other OO languages, like Self, construct everything at runtime by copying and modifying the objects found in the libraries, and therefore do not really have a base class that can be fragile. Some languages, like Java, have extensive documentation on what changes are safe to make without causing FBI problems.

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────